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NETWORK MEASUREMENT CONFIGURATION APPARATUS 

This application claims Japanese Patent 
application. NO. 2002-291459 tiled on October 3, 2002 . 
The entire content, of which are incorporated herein 
by reference for all purpose. 

BACKGROUND OF THE INVENTION 

The present invention relates to a network 
0 measurement configuration apparatus which selects, 
b ased on a user request, a meter for measurement 

► ,„^v and sets a measurement rule on 
traffic in a network, ana sees 

the IP meter thus selected. 

as a means for measurement traffic 
l6 characteristics in the network, such as transfer delay 
and packet loss, for example, it is known to carry out 
measurement by capturing data flowing through the 
network, utilizing a plurality of capturing devices 
.hereinafter referred to as "IP meters", arranged 
20 within the network, and by collecting the data thus 
captured by a measurement server. 

in the IPPM (IP Performance Metrics) of IETF (The 
mternet Engineering Task Force), methods for 
calculating delay time, loss and the like of a packet 
25 flowing through the network, by use of IP meters 

dl sposed at two positions, are defined in RFC 26,9 and 
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RFC 2680. 

in RFC 2722, measurement system architecture is 
defined, and a configuration of an administrative 
manager for setting a measurement ruie, an IP meter 
5 and a reader for collecting information from the IP 
meter are defined therein. However, in the RFC 2722, 
it is not defined as to a method for selecting the IP 
meter on which the measurement rule is set. 

1Q SUMMARY OF THE INVENTION 

Generally, a user reguest as to the measurement 
of traffic characteristics is, for example, a demand 
for measurement regarding an arbitrary network path 
between terminals, and a measurable point is not 
16 specified. Therefore, it is necessary to select an 
IP meter on which the measurement rule is set, in 
response to the user request. 

However, in a large-scale network, plural types 
o, IP meters exist and they are arranged at various 
20 positions. Since the IP meter varies in available 
types of measurement, performance and workload, 
according to an IP meter type, it is nectary to select 
an IP meter corresponding to the user request, 
considering the measurable point, available 
25 measurement types, workload and the like of each IP 
met er. Therefore, there has been a large burden on 
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an administrative operator. 

An object of the present invention is to provide 
a network measurement oonf igur a t i on apparatus which 
selects, based on a user request, an IP meter for 
5 measurement traffic in a network, and sets a 

measurement rule on the IP meter thus selected. 

in order to solve the problem as described above, 
according to the present invention, there is provided 
a network measurement configuration apparatus 
10 connected to a network having a plurality of 

m easurement devices arranged therein, which measures 
traffic data in the network based on a measurement rule, 
comprising, 

a receiving means which receives a user request 
16 including path information and a measurement type, 
a measurement device selecting means which 
selects a measurement device responsible for a 
measurement based on the user request, and 

a measurement rule setting means which sets a 
20 measurement rule in the measurement device thus 
selected . 

Here, the network measurement configuration 
apparatus further comprising, 

a measurement device information storing means 
25 which stores a measurable traffic data type and a 
measurable network range in each of said plurality of 
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measurement devices, wherein, 

said measurement device selecting means selects 
as a measurement device responsible for the 
measurement, a measurement device which includes in 
the measurable network range a measurable point 
obtained by path information included in the user 
request, and which is capable of measurement traffic 
data relating to the measurement type included in the 
user request. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a block diagram showing a configuration 
of QoS analysis system 100 to which the present 
invention is applied and a network 10, which is 
targeted for measurement by the QoS analysis system 
100. 

Fig. 2 is a diagram for explaining processing 
operations of each module of a task distributor 15, 
upon receipt of a user request 51. 
) Fig. 3 is a diagram showing a data structure of 

a service management database 108a. 

Fig. 4 is a diagram showing a data structure of 
a measurement characteristic database 108b. 

Fig. 5 is a diagram showing a data structure of 
5 a meter information database 108c. 

Fig. 6 is a diagram showing a data structure of 
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10 



15 



20 



meter 1 1 . 

Fig. 1 is a flowchart for explaining processing 
operations of each module of the task distributor 15, 
when the already-set user reguest 51 is edified. 

Fig 8 is a flowchart for explaining processrng 
operations of each module of the task distributor 15, 
when the already-set user reguest 51 is deleted. 

Fig. 9 is a diagram showing a process for 
monitoring the IP meter 11 and inter-module 
relationship when a problem occurs on the IP meter 11. 

Fig 10 is a flowchart showing a processrng 
operation of a reaction module 107 when it is notified 
of alarm from a meter monitoring module 106. 

DE TAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Preferred embodiments of the present inventron 
will be explained in detail with reference to the 

attached drawings. 

Fig . 1 is a block diagram showing a configuration 
of Qos (Qualify of Service, analysis system 100 to 
which the present invention is applied and a network 
10, which is targeted for measurement by the QoS 
analysis system 100. 

The network 10 is configured by connecting 
network segments including terminals 20 via network 
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devi ces 30 such as routers. Xn the network 10, a 
plurality of IP meters 11 are arranged tor measurement 
traffic of the network 10. The IP meter 11 measures, 
according to a given measurement rule, a traffic 
5 regarding a servioe level, such as number, size and 
throughput of packets targeted for measurement. 
Th ere are various IP meters, distributed broadly 
within the network 10, such as Incorporated in the 
network device 30, or arranged Independently. 

A QoS server 12, a service level management server 
13 (referred to as »SL management server 13",, and a 
task distributor 15 functioning as a network 
measurement configuration apparatus are connected to 
the network 10. Those units constitute the QoS 
16 analysis system 100. The OoS analysis system 100 may 
he configured with a plurality of devices as shown rn 
Flg . I. Alternatively, it may be configured on a 

single device. 

The QOS server 12 collects the traffic data 
20 measured by the IP meter 11, and calculates traffic 
characteristics of the network 10, such as delay time, 

j = = transfer volume per unit 
packet loss, and maximum data transfer 

of time, and Jitter (delay time dispersion,. 

The SL management server 13 determines based on 

26 the calculated result from the QoS server 12, whether 

or not the traffic characteristics of the network 10 
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satisfy the service level relating to the user request 
51, which will be described below. Then, if necessary, 
the SL management server notifies a user of the 
determination result and the like. 

The task distributor 15 receives the user request 
51 that was described about service level, and selects 
the IP meter 11 to carry out the measurement. The task 
distributor 15 generates measurement rules and the 
like based on the service level relating to the user 
10 request, and notifies the IP meter 1! having been 
selected, the QoS server 12 and the SL management 
server 13 of the measurement rules and the like thus 
generated . 

The task distributor 15 comprises a request 

• • ^HniP 101 a measurement task derivation 
15 receiving module iui, d 

module 102, a task generating module 103, a task 
distribution module 104, a communication module 105, 
a meter monitoring module 106, a reaction module 107 
and a group of databases 108. The task distributor 
20 15 may be configured based on software, for example, 
in a personal computer, a workstation and the like. 
Alternatively, it may be configured with hardware 
having respective functions. 

The reguest receiving module 101 receives the 

= ( - m and notifies the measurement task 
25 user request 51, ana nom 

derivation module 102 of the reception. 
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in the present embodiment, the user request 51 
includes information regarding a user who makes the 
request, and information regarding a service level 

thus requested. 

The information regarding the user who makes the 
request can be a user identifier for identifying the 
user who has made the request. The information 
regarding the requested service level further includes 
information regarding the traffic characteristic to 
be measured, such as path information (e.g., terminal 
terminal B and so on), measurement types (e.g., 
delay time, packet loss, throughput and so on), and 
monitoring information such as allowable threshold 
(e .g., within 10 milliseconds and so on) of the service 
Level and a measurement time (start time, end time and 
A format of the user request 51 is defined 



A 



so on ) 



in advance . 

The measurement task derivation module 102 
extracts from the user request 51 thus received, 
information regarding the service level, and generates 
measurement request information 52 for calculating 
traffic characteristics, and service level task 
information 53 for monitoring the service level (see 
Fig. 2) . 

The task generating module 103 determines a task 
to be performed in the IP meter 11 and the QoS server 
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12 , so as to calcuiate traffic characteristics 
req uired tor^itorin, the service level relating to 

the user request 51. 

The task distribution module 104 specifies an 
meter X1 to perform the traffic measurement, and 
gen erates a measurement rule to he set in the !P meter 

11 thus specified. 

The communication module 105 controls a 
communication between the tast distributor IS and IP 
.etar 11, the QoS server 12 and the S, management server 



13 . 



The meter monitoring module 106 monitors a status 

of the IP meter 11 . 

When a trouble occurs on the IP meter 11, the 
15 taction module 10, allows another XP meter 11 to carry 
out an alternative measurement. 

The g roup of databases 108 stores information to 
be used in the tas, distributor 15. I- the present 
embodiment, the group of databases 108 includes a 
se „ice management database ( SMDB) 108a, a measurement 
characteristic database (MMDB) 108b, a meter 
information database (MCDB ) 108c and a network 
architecture management database (NTDB ) 108d. 

The service management database 108a is a 
database to manage information per user reguest 51. 
Fig 3 is a diagram showing an example of a data 
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structure of the service management database 108a. As 
shown in Fig. 3, the service management database 108a 
ma nages user information data 301, including reguest 
identifier 302, user identifier 303, measurement rule 
identifier 304, QoS calculation identifier 305, start 
time 306, end time 307 and requesting status 308. 

The reguest identifier 302 is to identify the user 
request 51 . 

The user identifier 303 is to identify the user 
who made the request. 

The measurement rule identifier 304 is to 
identify a measurement rule to be set in the IP meter 
11 based on the user reguest 51. 

The QoS calculation identifier 305 is to identify 
a QoS calculation rule to be set in the QoS server 12 
based on the user request 51. 

The start time 306 and the end time 307 
respectively indicate a start time and an end time for 
carrying out the measurement based on the user reguest 

The requesting status 308 indicates a status of 
the QoS analysis system 100 regarding the user 
information data 301, in response to the user reguest 
51 . For example, a status of a QoS analysis system 
j may be, for example, "on receiving request", "end of 
receiving", "on starting measurement" and >.n ending 



10 



HT1842 



10 



measurement" and the like. 

The measurement characteristic database 108b is 
a database which associates each measurement type with 
a necessary number of IP meters (including types), a 

12 Fig 4 is a diagram showing an example of the 
measurement characteristic database 108b. As shown 
in Fig. 4, the measurement characteristic database 
10 8b manages in a table format (measurement means 
table, 401, measurement type 402, number of IP meters 
to be used 403, IP meter task 404, and QoS server task 
405 . 

For example, in measurement a packet size and a 
number of packets (VOLUME ) as one type of measurement, 
15 there are provided tasks of the IP meter 11, i.e., a 
method for calculation by the IP meter 11 itself 
(VOLUME CALC ON METER) and a method for transferrin, 
the captured packet, as it is, to the QoS server 12 
( PACKET COPY) or transferring the captured packet 
20 after condensed ( CRC.CONDENSE , . the calculation 

is performed on the IP meter 11, a task on the QoS server 
12 is not necessary, since the QoS server 12 is capable 
o£ using the resulted information as it is (NONE) . In 
tne other cases, the QoS server 12 performs a task to 
25 measure byte size information and packet number 

information by use of the packet thus transferred 
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(VOLUME_CALCURATION) . 

T ^ M as„e.ent ,eans table 401 is g enerated by 

in th . measurement characteristic database 108b. 

The meter information database (MCDB ) i08c is a 
datab ase to mana 9 e information re.ardin, the IP meter 

i -\ n Fi a 5 is a diagram 
H included in the network 10. Fig. 

ip of a data structure of the meter 
showing an example of a data 

information database 108c. As shown in Fig- 5, e 

met er information database 10Bc manages IP ..t.r 

..formation 5 01, including IP *eter identifier 502, 

. , ntifier 502, I P address 503, port number 
IP meter identifier :u^, 

^^■nf- S05, measurement 
504, monitoring segment bus, 

ch aracteristic SO,, time synchronism 507 , maximum 
S number of rules 503, current number of rules 509 

. v^-io-r 502 is to identify the 
The IP meter identifier 502 is 

IP meter 11. 

The IP address 503 is an IP address of the IP meter 
!0 u. which is used when the tas* distributor 15 

transmits a command and the li*e to the IP meter 1 

The port number 504 is a port number on the 
n eter 11, so as to receive a command and the 11*. from 
the task distributor 15. 

Th e monitors se g ment 505 indicates a networ* 
seg ment, as to which the IP meter 11 is capable of 
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performing the traffic measurement. 

The measurement characteristic 506 indicates a 
task which the XP meter ii is capable of performing. 
Fo r example, if ( VL_CALC_ON_METER) is included, the 
XP mater 11 is capable of calculating statistical 
formation, and if ,CRC_CON D ENSE, is included, the 
IP meter is capable of providing pacxet informatron 

of condensed type. 

Th e time synchronism 507 indicates an existence 
or nonexistence of a time synchronizing means and 
accuracy in synchronism on the IP meter 11. 

<= r11 i P , 58 indicates maximum 
The maximum number of rules 

nn.ber of rules acceptable by the IP meter 11, and the 
curre nt numher of rules 50* indicates the number of 
rul es which is currently used for carrying out the 
me asurement by the IP meter 11. 

Th e IP meter status 510 indicates a current status 
of the IP meter 11. In the present embodiment, the 
IP meter 11 can he in any one of the statuses, x.e 
0 normally activated (NORMAL) CPU usage rate in the 
meter n becomes high (WARNING) , and the IP meter 
is not activated (DOWN) . 

T ne last update date and time 511 indicates a date 
and time -en the current number of rules 50* or the 
26 IP meter status 510 is updated. 

In th e »eter information database 108c, the 
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administrative operator stores in advance the IP meter 
identifier 502, IP address 503, port number 504, 
monitoring segment 505, measurement characteristic 
506, time synchronism 501 and the maximum number of 
rules 508. As to the IP meter status 510, the meter 
m onitoring module 106 periodically inquires the IP 
me ter 11 and updates the IP meter status as necessary. 

The meter information database (MCDB ) 108c is 
provided with a measurement rule management table (not 
shown) for storing the measurement rule data to be set 
in the IP meter 11, separately from the IP meter 
information 501. A format of the measurement rule 
data which is stored in the measurement rule management 
table will be described below. 

The network architecture management database 
!08d is a database to manage configuration information 
of the network 10. The network architecture 
m anagement database 108d holds relationships in 
connection, for example by unit of segment, thereby 
m anaging the configuration information of the network 
10. Further, the network architecture management 
database 108d also manages, directly or indirectly, 
the identifier, IP address and relationships in 
connection of each terminal 20 included in the network. 
The configuration information of the network 10 that 
network architecture management database 108d manages 
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can be obtained from the network controller. 

It is to be noted that the group of databases 108 
is capable of storing another type of data, if 
necessary, without being limited to the data as 
described above. 

N ext, with reference to Fig. 2, processing 
operations of each module of the task distributor 15 
upon receipt of the user reguest 51 will be explained. 

This process starts when the reguest receiving 
module 101 receives the user request 51 (S101). 

The request receiving module 101 notifies the 
m easurement task derivation module 102 of the user 
request 51 thus received (S102) . 

When the measurement task derivation module 102 
receives the user request 51, it registers user 
information data 301 based on the user reguest 51 rn 
the service management database 108a (S103). 
Specifically, an identifier is set to the received user 
reguest 51, and it is stored in the request identifier 
302 Then, the measurement task derivation module 102 
sets user information based on the user identifier of 
the received user request 51, and sets the start time 
and end time based on the information regarding the 
service level. If the request is continuous, a value 
5 indicating "continuation" is set in the end time 307 . 
Then, the reguesting status 308 is set as "on receiving 
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request ,ON GOING) " • At this stage, there is no 
setting as to the measurement rule identifier 304, and 
the QoS calculation identifier 305. 

H.xt, the .eas.re.ent task derivation module 102 
extracts from the received user request 51, 
formation regarding the service level, and generates 
ser vice level task information 53 for monitoring the 
service level. (S104). For example, if the 
formation regarding the service level has a meaning 
that "delay time from terminal A to terminal B is within 
10 milliseconds", information meaning that 
monitoring to Keep the resulted value hy delay time 
m easurement is to he within the 10 milliseconds" x. 
set as the service level task information 53. Then, 
the measurement task derivation module 102 notifies 
the task distribution module 104 of thus generated 
ser vice level tasx information 53 ,3105,. At this 
timing, the request identifier 302 is included and also 
notified. A rule for generating the service level 
0 tasx information 53 from the information regarding the 
service level and a format of the service level tasx 
information 53 are defined in advance. 

The measurement task derivation module 102 
extracts from the received user request 51 information 
» regarding the service level, and generates 

measurement request information 52 for calculating the 
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JS106) . For example, if the 
traffic characteristic (Siuoj 

in£ „™ ati on retrain, the service level has a meaning 
that "delay ti- from terminal A to tergal B is within 
10 billiseconds", information meaning that 
6 measurement from terminal A to terminal B (path 
information, relates to delay time measurement 
measurement type," is set as the measurement revest 
information 52. Then, measurement tas, derivation 
ffi odule 102 notifies the tasX generating module 103 of 
10 th e measurement reguest information 52 thus generated 
(S107) . At this timing, the reguest identifier 302 
is included and also notified . A rule for generating 
th e measurement reguest information 32 from the 
information regarding the service level and a format 
16 of th e measurement reguest information 52 are defined 
in advance. 

The tasK generating module 103 having received 
th e measurement reguest information 52 refers to the 
m easurement characteristic database 108b. and 

f TP meter 11 prepared for the 
20 extracts the number of IP meter 

■guided in the measurement request 
measurement type included in 

„ T p TnPter 11/ and a task 
c;o a 1-ask m the lr metei xx, 
information 52, a rasK 

in the 0OS server 12 ,3108, . Then, the tasK generating 
mod ule 103 notifies the tas* distribution module 10, 
25 of the information obtained by adding those results 
ab ove to the measurement reguest information 52, as 
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a measurement task 54 (S109). 

The task distribution module 104 refers to the 
meter information database 108c and the network 
architecture management database 108d based on the 
measurement task 54 received from the task generating 
module 103, and selects an IP meter 11 which performs 
the traffic measurement [S110) . 

specifically, the task distribution module 104 
identifies a segment including a point to be measured 
based on the path information in the measuring task 
54 and the network architecture management database 
!08d, and extracts an IP meter 11 which is capable of 
measuring traffic of the identified segment from the 
meter information database 108c. 

In addition, it is determined whether or not the 
IP meter 11 thus extracted is able to perform the task 
of the IP meter 11 indicated in the measurement task 
54, referring to the measurement characteristic 506 
and time synchronism 507 of the meter information 
database 108c. For example, in order to measure the 
delay time { ONE WAY DELAY ) as a measurement type, xt 
is necessary that the IP meter 11 thus extracted is 
provided with the time synchronizing means and is able 
to perform a task to condense and transfer a packet 
j ,CRC CONDENSE). The task distribution module 104 
determines whether or not the extracted IP meter 11 
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satisfies the rules above. 

Then, the task distribution module 104 refers to 
the meter information database 108c, and confirms 
whether or not the current number of rules 509 in the 
extracted IP meter 11 is equal to or less than the 
maximum number of rules 508. 

If the measurement characteristic and the like 
do not satisfy the request of the measurement task 54, 
or the current number of rules 509 is identical to the 
maximum number of rules 508 , it is determined that the 
pertinent IP meter 11 is incapable of measurement, and 
then, another IP meter satisfying the rules are 
searched. When it is sufficient to measure an 
arbitrary one point, such as the case that the 
measurement type is statistical data, the task 
distribution module 104 refers to the network 
architecture management database 108d, and obtains a 
segment which an end-to-end path targeted for 
measurement passes through. Then, an IP meter 11 
which is capable of monitoring the segment is searched. 

When an IP meter 11 satisfying the rules is 
selected, the task distribution module 104 generates 
a measurement rule to be set in the selected IP meter 
11 (Sill). The measurement rule thus generated is 
stored in the measurement rule management table in the 
meter information database 108c. When any IP meter 
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11 satisfying the rules cannot be selected, a user or 
a higher level application is notified of the result 
as error information. 

Fig. 6 is a diagram showing an example of a data 
structure of the measurement rule 601, which is to be 
set in the IP meter 11. As shown in Fig. 6, the 
measurement rule 601 comprises, a measurement rule 
identifier 602 which is an identifier to identify a 
measurement rule uniquely and is . set by the task 
distribution module 104, IP meter information 
indicating information regarding the IP meter 11 which 
captures a packet, a flow rule which is a filtering 
rule to perform filtering on the captured packet, and 
others 610 for storing the information that there are 
any other filtering rules. 

The IP meter information comprises IP meter 
identifier 603 and task 604. The IP meter identifier 
603 is an identifier of the IP meter targeted for 
setting the measurement rule, and has a common value 
with the one stored in the IP meter identifier 502 of 
the IP meter information 501. The task 604 indicates 
a task that IP meter 11 is to perform. 

in a flow rule to determine a packet to be captured, 
source addr es s / ne twor k mask 605 stores an address or 
a range of address of the source. The receiver 
address/network mask 606 stores an address or an 
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address range of the receiver. Source port 607 stores 
a port number which is used by the terminal at the 
source. Receiver port 608 stores a port number which 
is used by the terminal at the receiver. The protocol 
609 stores a protocol type of IP in higher level. 

If there is any other filtering rule than the flow 
rule above, the information of such filtering rule is 
stored in the others 610. As to this flow rule, it 
is not necessary to store all the information of the 
rules, only partial rules are stored as necessary, 
based on the path information for measurement, which 
is specified in the user request 51. 

When the measurement rule 601 is generated, the 
task distribution module 104 utilizes the 
communication module 105, and firstly, transmits a QoS 
calculation rule tc the QoS server 12 ,8112). Here, 
the QOS calculation rule includes, for example, the 
me asurement rule identifier 602 set in the measurement 
rule 601, and the address of the selected IP meter 11, 
the measurement type and the task of the QoS server. 
When this QoS calculation rule is normally received 
by the QoS server 12, QoS calculation identifier is 
notified from the QoS server 12. 

Next, the task distribution module 104 transmits 
SL monitoring information to the SL management server 
13 (S113) . Here, the SL monitoring rule includes, for 
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example, a QoS calculation identifier notified from 
the QoS server 12 and monitoring information of the 
service level task information 53 notified from the 
measurement task derivation module 102. 

The task distribution module 104 then transmits 
a measurement rule 601 to each of the selected IP meters 
11 (S114) . At this stage, if the measurement uses IP 
meters at two points, such as measurement delay time 
or packet loss, the measurement rule 601 is firstly 
set on the IP meter 11 which is close to the receiver 
terminal. Subsequently, the measurement rule 601 is 
set to the IP meter which is close to the source 
terminal . 

When the above transmission is successfully 
completed, the task distribution module 104 stores the 
measurement rule identifier and the QoS calculation 
identifier thus received, in the measurement rule 
identifier 304 and the QoS calculation identifier 305 
respectively, of corresponding user information data 
301 in the service management database 108a. Then, 
the requesting status 308 of the user information data 
301 is updated to "end of receiving" (S115) . 

Further, the task distribution module 104 updates 
the current number of rules 509 in the corresponding 
IP meter information 501 in the meter information 
database 108c. 
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According to the processes above, the task 
distributor 15 is able to select an IP meter 11 for 
measurement the network traffic based on the user 
request 51, and set therein a measurement rule. 

Next, processing operations of each module of the 
task distributor 15 in the case where the already-set 
user request 51 is modified will be explained with 
reference to the flowchart of Fig. 7. 

When the request receiving module 101 receives 
a modifying request, the measurement task derivation 
module 102 is notified of the information (S701) . The 
modifying request 58 includes a request identifier 302 
of the user information data 301 to be modified, and 
based on this request identifier 302, the measurement 
task derivation module 102 extracts the pertinent user 
information data 301 from the service management 
database 108a. Then, the measurement task derivation 
module 102 generates measurement request information 
52 and service level task information 53 (S702). 

The measurement task derivation module 102 
transmits the measurement request information 52 and 
the service level task information 53 thus generated 
to the task generating module 103 and the task 
derivation module 102, respectively. Further, the 
measurement task derivation module 102 notifies the 
task generating module 103 of the measurement rule 
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identifier 304 included in the user information data 
301, and notifies the task distribution module 104 of 
the QoS calculation identifier 305. 

The task generating module 103 which has received 
the measurement request information 52 refers to the 
measurement characteristic database 108b, and 
extracts the number of the IP meter 11 corresponding 
to the measurement type included in the measurement 
request information 52, a task in the IP meter 11 and 
a task in the QoS server 12. Then, the task generating 
module 103 notifies the task distribution module 104 
of the information as measurement task 54, obtained 
by adding to the measurement request information 52, 
the resulting information above and the measurement 
rule identifier 304 (S703) . 

The task distribution module 104 extracts a 
current measurement rule data, based on the received 
measurement rule identifier 304, from the measurement 
rule management table in the meter information 
database 108c. Then, the task distribution module 104 
compares the measurement rule data thus extracted with 
a measurement rule based on a new task. Consequently, 
if the measurement rule based on the new task is 
different from the already-set measurement rule data, 
a measurement rule deleting command is generated. For 
example, if a measurement of a path from terminal A 



24 



HT1842 



to terminal B is modified to a measurement of a path 
from terminal A to terminal C, one of the IP meters 
11 for performing the measurement is replaced. At 
this stage, a measurement rule for the IP meter 11 for 
performing the measurement on the newly added terminal 
C is generated, as well as generating information for 
deleting the measurement rule, for the IP meter 11 
which is subjected to the modification. (S704). 

The task distribution module 104 firstly 
transmits a QoS calculation rule for the modification 
to the QoS server 12 (S705) . The QoS calculation rule 
includes a QoS calculation identifier for the 
modification, as well as information identical to the 
rule at the time of initial setting. 

When the QoS server 12 normally receives the 
modification request, the task distribution module 104 
notifies the SL managing server 13 of an SL monitoring 
rule (S706). The SL monitoring rule includes a QoS 
calculation identifier and monitoring information and 
the like, which are obtained from the service level 
task information 53, transmitted from the measurement 
task derivation module 102. 

Then, the task distribution module transmits a 
measurement rule to be added/deleted to each of the 
IP meters 11 (S7 07 ) . 

If the data transmission as described above is 
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successfully completed, the task distribution module 
104 deletes the measurement rule data prior to the 
modification in the measurement rule management table 
in the meter information database 108c, and stores the 
measurement rule data after the modification. Then, 
a requesting status 308 of the user information data 
301 is updated to "end of receiving" (S7 08 ) . Further, 
the task distribution module 104 updates a current 
number of rules 509 in the corresponding IP meter 
information 501 in the meter information database 
108c . 

The operations as described above are the 
processing operations of each module of the task 
distributor 15 at the time when a modification is made 
to the already-set request. 

Next, processing operations of each module of the 
task distributor 15 when the already-set user request 
51 is deleted will be explained with reference to a 
flowchart in Fig. 8. 

When the measurement task derivation module 102 
receives a deleting request from the request receiving 
module 101, it extracts corresponding user information 
data 301 based on the request identifier. Then, a 
measurement rule identifier 304 and a QoS calculation 
identifier 305 are obtained from the user information 
data 301, and the measurement task derivation module 
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102 notifies the task generating module 103 of the 
obtained information (S801). 

The task generating module 103 does nothing, and 
notifies the task distribution module 104 of the 
obtained information as it is (S802) . 

The task distribution module 104 specifies a 
corresponding IP meter 11 based on the measurement rule 
identifier, and generates deleting information for 
deleting the already-set filtering rule (S803). 

Then, the task distribution module 104 notifies 
the QoS server 12 and the SL management server 13 of 
the QoS calculation identifier for the deletion (S8 04) . 
And then, it notifies each IP meter 11 of the deleting 
information (S805) . 

When all the requests are properly completed, 
the task distribution module 104 deletes the 
corresponding measurement rule data in the measurement 
rule management table in the meter information 
database 108c, and the user information data 301, and 
then updates the current number of rules 509 in the 
corresponding IP meter information 501 in the meter 
information database 108c (S806). 

The operations as described above are processing 
operations of each module of the task distributor 15 
at the time when the already-set request is deleted. 
Finally, processing operations of each module of 
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the task distributor 15 in the case where any problems 
occur on the IP meter 11 will be explained with 
reference to Fig. 9 and Fig. 10. 

Fig. 9 is a diagram showing relationships among 
5 each module in the processing for monitoring the IP 
me ter 11 and when a problem occurs on the IP meter 
itself . 

The meter monitoring module 106 periodically 
inquires the IP meter 11 via the communication module 
0 about the meter status (S901) . The meter monitoring 
m odule 106 updates the meter status 510 of the meter 
information database 108c, based on the inquiry result 
,3902). At this timing, if there is no response or 
the response in an abnormal status, the meter 
15 monitoring module 106 notifies the reaction module 107 
of an alarm including the IP meter identifier on which 
the problem has occurred (S903) . 

When the reaction module 107 receives the alarm, 
it obtains an alternative IP meter 11 according to the 
20 procedure as described below. Then, the reaction 

m odule 107 notifies the QoS server 12 of a new QoS 
calculation rule (S905), also notifies the SL 
m anagement server 13 of a new SL monitoring rule (390 6, , 
and adds a measurement rule to the alternative IP meter 

25 11 (S904 ) . 

Fig. 10 is a flowchart showing processing 
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operations of the reaction module 107, at the time when 
it is notified of the alarm from the meter monitoring 
module 106. 

The reaction module 107 starts this processing 
wh en it receives the alarm from the meter monitoring 
module 106 (S1001) . 

The reacticn module 107 obtains a measurement 
rul e 60! containing the corresponding identifier, from 
the IP meter identifiers included in the alarm. Then, 
based on the measurement rule identifier 602 of the 
measurement rule 601, user information data 301 
possible to be affected is extracted from the service 
management database 108a (S1002). 

Next, referring to the monitoring segment 505 of 
, the meter information database 108c, a network segment 
monitored by the IP meter 11 having the problem rs 
obtained . 

Then, it is also checked whether or not there is 
another IP meter 11 which captures the same segment 
0 ,51003,51004). If such IP meter 11 does not exist, 
the reaction module 107 obtains a segment constituting 
a path, from the path information and the network 
architecture management database 108d ,31005, . Then, 
the reaction module 107 obtains a segment next to the 
„ segment which captures the IP meter 11 having the 
problem (51006), and determines whether or not there 
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is a n IP meter 11 which captures the next segment (S1007, 
S1008) . 

If such IP meter 11 exists, and It is available 
for measurement, the reaction module notifies the QoS 
server 12 that information will he collected from the 
new IP meter 11, and also notifies the SL management 
server 13 that it is the measurement through an 
alt ernative path. Then, the reaction module 107 sets 
a m easurement rule to the alternative IP meter 11 
, sl0 09). When the processing above is normally 
oompleted, the IP meter identifier in the 
corresponding measurement rule data in the measurement 
r ule management table in the meter information 
database 108 is replaced by the identifier of the 
15 alternative IP meter 11. 

subsequently, the reaction module 107 sends a 
warning notification as to the change in the 
.easurement rule, to the higher level application 
(S1010) . 

for measurement does not exist, the reaction module 
107 searches another adjacent segment on the path, and 
repeats a process to find whether or not any available 
IP m eter 11 exists ,31011 ... S1008,. Then, if the 
26 number of the segments thus searched reaches a 

threshold or more, the process is stopped and the 
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reaction module 107 sends to the higher level 
application an alar, notification indicating that the 
alteration is unsuccessful (S1012). 

According to the processes above, the task 
distributor 15 automatically selects an IP meter 11 
relating to the measurement based on the user request, 
and is capable of setting measurement rules and the 
lik e in the IP meter 11, QoS server 12 and the SL 
management server 13. 

As described above, according to the present 
invention, a network measurement configuration 
apparatus is provided, which selects an IP meter for 
m easurement traffic in a network, based on a user 
request, and sets a measurement rule in the IP meter. 
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